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(57) ABSTRACT 

A novel method and apparatus is disclosed for performing 
seamless handoff of a mobile station (MS) between Radio 
Access Networks (RANs) that use different types of wireless 
interfaces. The described embodiments enable an MS to 
handoff between different RANs without causing routing 
ambiguity, and without substantial loss of network data. 
Upon moving from the coverage area of a first RAN using 
a first wireless interface to the coverage area of a second 
RAN using a second wireless interface, an MS determines 
whether routing ambiguity may result from the change of 
RAN and, based on the determination, triggers a re-regis- 
tration of its network address. A foreign agent (FA) within a 
packet data serving node (PDSN) monitors network address 
re-registrations in order to determine whether multiple 
RAN-PDSN (R-P) connections are being created for the 
same MS. Based on this determination, the PDSN terminates 
redundant R-P network connections resulting from move- 
ment of the MS between different RANs. 
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METHOD AND APPARATUS FOR HANDOFF OF A 
WIRELESS PACKET DATA SERVICES 
CONNECTION 

BACKGROUND 

[0001] I. Field 

[0002] The present invention relates to wireless commu- 
nications. More particularly, the present invention relates to 
a novel method and apparatus for performing seamless 
handoff of a mobile station between radio access networks 
having different wireless interfaces during wireless packet 
data service operation. 

[0003] D. Background 

[0004] The use of code division multiple access (CDMA) 
modulation techniques is one of several techniques for 
facilitating communications in which a large number of 
system users are present. Other multiple access communi- 
cation system techniques, such as time division multiple 
access (TDMA), frequency division multiple access 
(FDMA) and AM modulation schemes such as amplitude 
companded single sideband (ACSSB) are known in the art. 
These techniques have been standardized to facilitate inter- 
operation between equipment manufactured by different 
companies. Code division multiple access communication 
systems have been standardized in the United States in 
Telecommunications Industry Association TIA/EIA/IS-95- 
B, entitled "MOBILE STATION-BASE STATION COM- 
PATIBILITY STANDARD FOR DUAL-MODE WIDE- 
BAND SPREAD SPECTRUM CELLULAR SYSTEMS", 
and referred to herein as IS-95. In addition, a new standard 
for CDMA communication systems has been proposed in the 
United States in Telecommunications Industry Association 
(TIA), entitled "Upper Layer (Layer 3) Signaling Standard 
for cdma2000 Spread Spectrum Systems, Release A — Ad- 
dendum 1", dated Oct. 27, 2000, and referred to herein as 
"lx." An additional standard for providing high speed data 
services has been proposed in the HA, entitled "cdma2000 
High Rate Packet Data Air Interface Specification," dated 
Oct. 27, 2000, and referred to herein as "HDR " 

[0005] The International Telecommunications Union 
recently requested the submission of proposed methods for 
providing high rate data and high-quality speech services 
over wireless communication channels. A first of these 
proposals was issued by the Telecommunications Industry 
Association, entitled "The IS-2000 ITU-R RTT Candidate 
Submission." A second of these proposals was issued by the 
European Telecommunications Standards Institute (ETSI), 
entitled "The ETSI UMTS Terrestrial Radio Access (UTRA) 
ITU-R RTT Candidate Submission", also known as "wide- 
band CDMA" and hereinafter referred to as "W-CDMA" A 
third proposal was submitted by VS. TG 8/1 entitled "The 
UWC-136 Candidate Submission", hereinafter referred to as 
"EDGE." The contents of these submissions is public record 
and is well known in the art. 

[0006] IS-95 was originally optimized for transmission of 
variable-rate voice frames. Subsequent standards have built 
on the standard to support a variety of additional non-voice 
services including packet data services. One such set of 
packet data services was standardized in the United States in 
Telecommunications Industry Association T1A/EIA/IS-707- 
A, entitled "Data Service Options for Spread Spectrum 
Systems", incorporated by reference herein, and hereafter 
referred to as "IS-707." 



[0007] IS-707 describes techniques used to provide sup- 
port for sending Internet Protocol (IP) packets through an 
IS-95 wireless network. Packets are encapsulated into a 
featureless byte stream using a protocol called Point-toPoint 
Protocol (PPP). Using PPP, IP datagrams having lengths of 
up to 1500 bytes can be transported over a wireless network 
in segments of arbitrary size. The wireless network main- 
tains PPP state information for the duration of the PPP 
session, or as long additional bytes may be sent in the 
continuous byte stream between the PPP end points, 

[0008] A remote network node such as a personal or laptop 
computer (PC) connected to a packet-data-capable wireless 
mobile station (MS) may access the Internet through a 
wireless network in accordance with the IS-707 standard. 
Alternatively, the remote network node such as a web 
browser may be built-in to the MS, making the PC optional. 
An MS may be any of a number of types of devices 
including, but not limited to PC card, personal data assistant 
(PDA), external or internal modem, or wireless phone or 
terminal. The MS sends data through the wireless network, 
where it is processed by a packet data serving node (PDSN). 
The PPP state for a connection between an MS and the 
wireless network is typically maintained within the PDSN. 
The PDSN is connected to an IP network such as the 
Internet, and transports data between the wireless network 
and other entities and agents connected to the IP network. In 
this way, the MS can send and receive data to another entity 
on the IP network through the wireless data connection. The 
target entity on the IP network is also called a correspondent 
node. 

[0009] The MS must obtain an IP address before sending 
and receiving IP packets over the IP network. In some early 
implementations, the MS was assigned an IP address from a 
pool of addresses belonging exclusively to the PDSN. Each 
PDSN was connected to one or more Radio Access Net- 
works (RANs) associated with a limited geographical area. 
When the MS moved out of the area served by the first 
PDSN, data addressed to the MS through the first PDSN 
could not reach the MS. If the MS moved into an area served 
by a second PDSN, the MS would have to be assigned a new 
IP address from the address space of the second PDSN. Any 
ongoing connection with a correspondent node that was 
based on the old IP address would be abruptly terminated. 

[0010] In order to prevent connections from being lost 
when moving from PDSN to PDSN, MSs use a protocol 
known as mobile IP. The Internet Engineering Task Force 
(IETF 7 ) has standardized mobile IP in request for comments 
(RFC) 2002, entitled "IP Mobility Support," published in 
October 1996, and well known in the art. The use of mobile 
IP in cdma2000 networks has been standardized in EIA/ 
1TA/IS-835, entitled 'Wireless IP Network Standard," dated 
June, 2000, and referred to herein as "IS-835 " In mobile IP, 
the PDSN does not provide an IP address from its own pool 
of addresses. Instead, the PDSN acts as a foreign agent (FA) 
that facilitates assignment of an address from a home agent 
(HA) located somewhere in the IP network. The MS com- 
municates through the FA to the HA, and receives an IP 
address assigned from an address pool belonging to the HA 
When the MS moves from a first PDSN to a second PDSN, 
the MS communicates through the second PDSN and FA in 
order to re-register its existing IP address with the HA 

[0011] IS-707 and IS-835 describe a dormant mode, in 
which a wireless link that was established for transporting 
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packet data, but which is idle for a certain period of time, 
may be reclaimed by the network without terminating the 
associated PPP session. When the flow_ of packet data 
resumes, the wireless link is re-established without having tcr 
repeat PPP configuration and negotiation. Preserving the ' 
£PPP state wh^thejwireless linkjiasj>een tenmnated thu? 

enables the MS and the wireless network to resume sending* 
jacket data more quickly than if the PPP state had to be 
/re-established. ' ~ ^ _ — — 

[0012] The proposed lx standard provides mechanisms to 
update routing between an HA and multiple PDSNs and lx 
RANs. The proposed HDR standards provide mechanisms 
to update routing between an HA and multiple PDSNs and 
HDR RANs. Both the HDR and lx standards can effectively 
update packet routing even when an MS changes RANs 
while in dormant mode, as long as the MS does not move to 
a RAN using a different type of wireless interface. For 
example, if an MS moves from a lx RAN to an HDR RAN 
while dormant, routing ambiguities or redundancies can 
occur, and packets can be lost. As these various systems are 
deployed, there will be a need for mechanisms to effectively 
update routing of packets to an MS moving between RANs 
using different types of wireless interfaces. 

SUMMARY 

[0013] Embodiments of the present invention are directed 
to enabling seamless handoff of a mobile station (MS) 
between Radio Access Networks (RANs) that use different 
types of wireless interfaces. The embodiments described 
herein enable an MS to handoff between different RANs 
without causing routing ambiguity, and without substantial 
loss of network data. Upon moving from the coverage area 
of a first RAN using a first wireless interface to the coverage 
area of a second RAN using a second wireless interface, an 
MS determines whether routing ambiguity may result from 
the change of RAN and, based on the determination, triggers 
a re-registration of its network address. A foreign agent (FA) 
within a packet data serving node (PDSN) monitors network 
address re-registrations in order to determine whether mul- 
tiple RAN-PDSN (R-P) connections are being created for 
the same MS. Based on this determination, the PDSN 
terminates redundant R-P network connections resulting 
from movement of the MS between different RANs. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0014] The features, objects, and advantages of the present 
invention will become more apparent from the detailed 
description set forth below when taken in conjunction with 
the drawings in which like reference characters identify 
correspondingly throughout and wherein: 

[0015] FIG. 1 is a diagram of a wireless system configu- 
ration using only lx radio access networks (RANs); 

[0016] FIG. 2 is an exemplary message flow diagram 
depicting assignment of an IP address to an MS 2 in 
accordance with the mobile IP standard; 

[0017] FIG. 3 is a diagram of a wireless system configu- 
ration using only HDR radio access networks (RANs); 

[0018] FIG. 4 is a block diagram of a subscriber station 
apparatus configured in accordance with an embodiment of 
the present invention; 



[0019] FIG. 5 is a flowchart showing an exemplary pro- 
cess used by an MS when handing off between a lx RAN 
and an HDR RAN capable of performing International 
Mobile Station Identity (IMSI) authentication, in accordance 
with an embodiment of the present invention; 

[0020] FIG. 6 is a flowchart showing an exemplary pro- 
cess used by an MS when handing off between a different 
RANs, where it is not known whether the HDR RANs are 
capable of performing IMSI authentication, in accordance 
with an embodiment of the present invention; 

[0021] FIG. 7 is a flowchart of a handoff process for a 
destination network including a destination PDSN and a 
destination RAN, and in accordance with an embodiment of 
the present invention; and 

[0022] FIG. 8 is a block diagram of an exemplary MS 
configured in accordance with an embodiment of the present 
invention. 

DETAILED DESCRIPTION 

[0023] The word "exemplary" is used in this application to 
mean "serving as an example, instance, or illustration." Any 
embodiment described as an "exemplary embodiment" is 
not to be construed as necessarily preferred or advantageous 
over other embodiments described herein. 

[0024] FIG. 1 depicts a network configuration in a system 
using only lx radio access networks (RANs) 32, 34, 36. In 
an exemplary embodiment, a personal or laptop computer 
(PC) 4 is connected to a wireless mobile station (MS) 2 
through a data connection 12. The data connection 12 
between the PC and the MS 2 may use a physical cable such 
as an ethernet, serial, or universal serial bus (USB) cable. 
Alternatively, the data connection 12 may be a wireless 
connection such as an infrared or other optical connection or 
a ratio connection such as Bluetooth or IEEE 802.11. As 
previously discussed, the PC may alternatively be incorpo- 
rated into the MS 2 to enable network access through a 
single device. In the figure, the MS 2 changes its physical 
location among coverage areas 6, 8, 10 associated with 
RAN a 32, RAN B 34, and RAN C 36 respectively. RAN A 32 
and 34 are connected to PDSNj 14, which in turn is 

connected to an IP Network 18. RAN C 36 is connected to 
PDSN 16, which is then connected to the IP Network 18. 
Also accessible through the IP Network 18 are a home agent 
(HA) 20, an authentication, authorization and accounting 
(AAA) Server 22, and a correspondent node 24. Multiple 
additional PDSNs, HAs, AAA Servers, and correspondent 
nodes may be connected to the IP Network 18 but are 
omitted for simplicity. 

[0025] When the MS 2 initially connects to a RAN, for 
example RAN A 32, the MS 2 must obtain an IP address from 
some entity that is connected with the IP network 18. As 
discussed above, in early implementations the MS 2 was 
assigned an IP address from a pool of addresses allocated to 
the PDSN 14. Because all packets bearing an IP address 
from that pool of addresses would be routed to the PDSN 14 
by the IP network 18, the PDSN 14 could then route those 
packets to the corresponding MS 2. However, if the MS 2 
moved out of the coverage of any RAN connected to the 
PDSN 14, the PDSN 14 would no longer be able to forward 
packets to the MS 2. For example, if the MS 2 moved from 
the coverage area 6 of RAN A 32 to the coverage area 10 of 



06/29/2004, EAST Version: 1.4.1 



US 2002/0068570 Al 



3 



Jun. 6, 2002 



RAN C 36, the MS 2 would have to obtain a new IP address 
from the address pool of PDSN 2 16. Any packets sent to the 
old address associated with PDSNj 14 would have to be 
discarded, and any ongoing network connections using the 
old address could no longer be used. 

[0026] In more recent mobile IP implementations, the MS 
2 instead obtains its IP address from an HA 20 connected to 
the IP network. After obtaining an address from the pool 
associated with HA 20, mobile IP protocol enables the MS 
2 to receive packets bearing that IP address through any of 
multiple RANs, 32, 34, or 36, or through any of multiple 
PDSNs 14 or 16. As an alternative to dynamic allocation of 
an IP address from the HA 20, the MS 2 may also have an 
IP address within the address pool of HA 20 provisioned in 
the memory of the MS 2 ahead of time, for example upon 
activation of services. 

[0027] FIG. 2 is an exemplary message flow diagram 
depicting assignment of an IP address to an MS 2 in 
accordance with the mobile IP standard. First, the MS 2 
originates a wireless link to a RAN connected to PDSN 14 
and sends a first message 202 through a RAN to the PDSN 
14. If the MS 2 has an international mobile station identity 
(IMSI), the MS 2 sends the IMSI in the first message 202. 
The first message 202 may be one of several different types, 
depending on the type of wireless interface supported by the 
RAN or the connection state of the wireless link between the 
MS 2 and the RAN. For example, the first message 202 may 
be an origination message if the MS 2 is not connected to the 
RAN, or may be an agent solicitation message if the MS 2 
is already communicating over a wireless link with the 
RAN. Though the numbering in the example shown indi- 
cates PDSN a 14, the first message 202 could also be sent 
through a RAN connected to another PDSN such as PDSN 2 
16. 

[0028] In response to the first message 202, the PDSN 14 
responds with a message 204 containing an agent advertise- 
ment and an authentication challenge. The agent advertise- 
ment identifies the address of the foreign agent (FA) within 
the PDSN 14. The authentication challenge is part of a 
handshake that prevents other network entities from acci- 
dentally or maliciously using the network identity to inter- 
cept data packets intended for the MS 2. The MS 2 and the 
authentication, authorization, and accounting (AAA) server 
22 are programmed with shared secret information not 
available throughout the IP network 18. The shared secret 
information allows the AAA server 22 to verify the identity 
of the MS 2 before the MS 2 is allowed to send requests to 
the HA 20. If authentication with the AAA server 22 fails, 
then the MS 2 cannot request an IP address from the HA 20. 
In an exemplary embodiment, the shared secret takes the 
form of a user name and a password. 

[0029] Upon receiving the challenge in the message 204 
received from the PDSN 14, the MS 2 uses its shared secret 
information in combination with the challenge information 
to form a challenge response that will enable the HA 20 to 
verify the identity of the MS 2. For example, the MS 2 uses 
a one-way hashing function to combine the shared secret 
information with the challenge information. The MS 2 sends 
a message 206 back to the PDSN 14 containing the chal- 
lenge information, the challenge response, and a registration 
request. The PDSN 14 then forwards the three pieces of 
information to the AAA server 22 in a message 208. Using 



the same one-way hashing function, the AAA server 22 can 
verify the shared secret information used by the MS 2, even 
though the shared secret information itself is never sent 
through the network. The AAA server 22 can be one of 
several brands or types. In an exemplary embodiment, a 
Remote Authentication Dial In User Service (RADIUS) 
server is used. 

[0030] If the AAA server 22 determines that the challenge 
response from the MS 2 is valid, the AAA server 22 forwards 
the registration request 210 to the HA20. The HA20 has a 
pool of available IP addresses that it assigns to mobile 
network entities such as the MS 2. Any IP packet sent 
through the IP network 18 bearing a destination address 
from the HA's 20 pool of addresses are routed by the IP 
network 18 to the HA 20. Based on the contents of the 
registration request 210, the HA 20 forms a registration reply 
212 containing an IP address to be used as a source address 
in packets sent by the MS 2 to other network entities. The 
HA20 sends the response 212 to the FA in the PDSN 14. The 
FA records the IP address and associates it with and estab- 
lishes a RAN-PDSN (R-P) session. In an exemplary 
embodiment, the FA stores the R-P information in a table 
that is indexed according to IP address. To complete the 
assignment of the IP address to the MS 2, the PDSN sends 
a message 214 to the MS 2 through the RAN. The message 
214 contains the registration reply from the HA 20 and 
includes the IP address allocated to the MS 2. 

[0031] After its IP address has been registered, the MS 2 
may begin sending IP packets throughout the IP network 18. 
For example, the MS 2 may begin communicating with a 
correspondent node 24, such as a web server. Packets sent by 
the MS 2 bear the destination address of the correspondent 
node 24 and the source address assigned to the MS 2. All 
messages sent by the MS 2 are routed through the FA in the 
PDSN 14. The FA may send an outgoing packet straight into 
the IP network 18 or may encapsulate it in a larger packet 
addressed to the HA 20. If the latter approach is taken, the 
HA 20 decapsulates the packet received from the PDSN 14 
and forwards the decapsulated packet to its destination 
within the correspondent node 24. 

[0032] Responses from the correspondent node 24 will 
bear the destination address assigned to the MS 2 from the 
address pool belonging to the HA 20. All such messages arc 
routed by the IP network 18 to the HA 20. The HA 20 
inspects the destination address of each received IP packet 
to identify the MS 2 and the associated PDSN 14. Then, the 
HA 20 encapsulates the packet in a larger packet bearing the 
destination address of the PDSN 14. The encapsulated 
packet is received by the FA in the PDSN 14. The FA 
decapsulates the packet and finds the destination IP address 
of the decapsulated packet in its R-P table. The FA then 
forwards the packet through the RAN associated with the 
corresponding R-P session. To the MS 2, the mobile IP 
process is transparent except for a bit of added delay for all 
the encapsulation, decapsulation, and forwarding. 

[0033] In FIG. 1, the MS 2 is shown as being located in 
the coverage area 6 of RAN A 32. In FIG. 1, all the RANs 32, 
34, 36 use a lx type of wireless interface. Networks using a 
lx wireless interface use IMS Is to identify mobile stations. 
An MS 2 establishing a new wireless link sends its IMSI in 
the origination message. The RAN authenticates the IMSI 
by exchanging challenge and challenge response messages 
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with a home location register (HLR) (not shown). The HLR 
is part of a signaling system 7 (SS7) wireless phone network 
that is standardized and well known in the art Authentica- 
tion of IMS Is is accomplished using techniques similar to 
the one-way hash function techniques described above in 
association with mobile IP authentication. 

[0034] In an exemplary embodiment as shown in FIG. 1, 
the MS 2 first establishes a connection through a first lx 
RAN 32 and registers with the HA 20 as described above in 
association with FIG. 2. After mobile IP registration is 
complete, the MS 2 uses an address from the address pool 
of the HA 20, and sends packets using a PPP state within the 
FA in PDSN 2 14. In a lx system, PDSN a 14 identifies the 
MS 2 by its IMSI. Within the coverage area 6 of RAN A 32, 
the MS 2 monitors overhead messages broadcast from base 
stations in RAN A 32. Among other types if information, 
those overhead messages identify the packet zone ID (PZID) 
of RAN A 32. 

[0035] When the MS 2 leaves the coverage area 6 of 
RAN 32 and enters the coverage area 8 of RAN B 34, the MS 
2 decodes the overhead messages broadcast by the base 
stations in RAN b 34. The RAN B overhead messages contain 
a different PZID than that broadcast by base stations in 
RAN A . When the MS 2 detects the change in the PZID, it 
sends a "fake migration" to RAN B 34. In an exemplary _ 
embodiment, the origination message contains.the IMSI of , v 
iffic_MSj8J afdata^adv. to send-(DRS)-field, . an^a-ERE--- 
V_PZH> field. Becai^the.origmattoni^^^ 
-updajing.purposevtheJDRS field is set t o 0, indicating that 
/tEe'MS 2 does not have packet data" to send. If the MS^> 
happens to have new packet data to be sent to.thenetwork, 
✓it may originate a regjilaxi^Lusjng jua(^gmatidn^avjng a 
(1 in the DRSfieldrThe PREV_PZID field conuinsthePZID 
of the previoussystem to which the MS 2 was connected. 
RAN 34 receives the origination and forwards the IMSI and 
the pflEV_PZID of the MS 2 to its serving PDSN, PDSN a 
14. PDSN7l4 determines from the IMSI that the MS 2 has 
an existing PPP state within the PDSNj 14, and determines 
from the PREVPZID value that the MS 2 came from RAN A 
32. Because the PDSNj is connected to both the original 
RAN A 32 and the destination RAN B 34, the PDSN 2 can 
generally just redirect the same PPP state to the destination 
RAN 34. If, for some reason, PDSN^ 14 cannot redirect the 
same PPP state to the destination RAN 34, PDSNj 14 resets 
its PPP state and forces the MS 2 to establish a new PPP 
session. 

[0036] When the MS 2 leaves the coverage area 8 of 
RAN 34 and enters the coverage area 10 of RAN C 36, the 
MS 2 decodes the overhead messages broadcast by the base 
stations in RAN C 36. The RAN C 36 overhead messages 
contain a different PZID than broadcast by base stations in 
RAN B 34. When the MS 2 detects the change in the PZID, 
it sends a "fake origination" to RAN C 36 containing the 
IMSI of the MS 2, a DRS field having a value of 0, and a 
PREV_PZID field identifying the PZID of the previous 
RAN, RAN B 34. RAN C 36 receives the origination and 
forwards the IMSI and the PREV _PZID of the MS 2 to its 
serving PDSN, PDSN 2 16. Depending on whether the MS 2 
had previously been connected to PDSN 2 16, PDSN 2 16 may 
have a PPP state associated with the IMSI of the MS 2. 
Regardless of the existence of a previous PPP state, PDSN 2 
16 determines from the PREV PZID value that the MS 2 
came from a RAN connected to a different PDSN. PDSN 2 



16 cannot retrieve a PPP state from a different PDSN, and is 
consequently required to establish a new PPP session with 
the MS 2, If PDSN 2 16 had a previous PPP session set up 
with the MS 2, this means that PDSN 2 16 must discard that 
PPP session. 

[0037] After a new PPP session is established between the 
MS 2 and PDSN 2 16, PDSN 2 16 sends an agent advertise- 
ment message to the MS 2 identifying the address of the FA 
within PDSN 2 16. Because the address of each FA is 
different, the FA address of PDSN 2 16 will be different than 
the FA address of PDSNj 14. When the MS 2 receives an 
agent advertisement having a different address, the MS 
determines that it must re-register its IP address with the HA 
20. The MS 2 re-registers its IP address with the HA 20, for 
example according to the protocol described in association 
with FIG. 2. Using mobile IP authentication as described 
above, the HA 20 recognizes that the MS 2 has moved and 
is requesting the same IP address. If possible, the HA 20 
allocates the same IP address to the MS 2 and redirects 
messages destined for that address to PDSN 2 16. Generally, 
the HA 20 does not send notification of the redirection to the 
original PDSN, ?DSN 1 14. 

[0038] FIG. 3 depicts a network configuration in a system 
using only HDR RANs 42, 44, 46. The MS 2 is initially 
located in the coverage area 6 of RAN A 42. In FIG. 3, all the 
RANs 42, 44, 46 use an HDR type of wireless interface. 
Networks using an HDR wireless interface use Unicast 
Access Terminal Identifiers (UATIs) to identify mobile 
stations. 

[0039] An HDR RAN generally does not obtain an IMSI 
from an MS 2, but assigns an IMSI to each MS 2 primarily 
to allow identification of R-P sessions with a PDSN. By 
providing some IMSI support, an HDR network can use the 
same kind of PDSN used by lx systems. In general, a strictly 
HDR network does not perform any IMSI authentication, 
and is not connected to an SS7 wireless phone network. In 
an exemplary embodiment, a database of UATIs, IMS Is, and 
other information is distributed among HDR RANs in a 
wireless network. 

[0040] The MS 2 connects to an HDR system through a 
first HDR RAN, for example RAN A 42, and obtains a UAT1 
from RAN A 42. RAN A 42 then assigns a temporary IMSI to 
the MS 2 in order to enable packet data to be routed by the 
FA in PDSNj 14. Alternatively, if RAN A 42 is capable of 
authenticating the IMSI, RAN A 42 assigns the actual IMSI 
to the MS 2 in establishing the R-P link with PDSNj 14. If 
RAN A 42 is capable of authenticating the IMSI, it may do so 
using an Authentication Center on an SS7 network or using 
the AAA server 22. The MS 2 then registers with the HA 20 
as described above in association with FIG. 2. After mobile 
IP registration is complete, the MS 2 uses the IP address 
assigned to it by the HA 20, and sends packets using a PPP 
state within the FA in PDSNj 14. Within the coverage area 
6 of RAN A 42, the MS 2 monitors overhead messages 
broadcast from base stations in RAN A 42. In an exemplary 
embodiment, the overhead messages include information 
that enables the MS 2 to determine when it is located within 
the coverage area 6 associated with base stations of RAN A 
42. The overhead messages that allow the MS 2 to identify 
the RAN associated with a coverage area are referred to as 
a subnet mask When the MS 2 leaves one coverage area and 
enters another, the subnet mask received on the overhead 
channels will change accordingly. 
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[0041] When the MS 2 leaves the coverage area 6 of 
RAN a 42 and enters the coverage area 8 of RAN B 44, the MS 
2 decodes the overhead messages broadcast by the base 
stations in RAN b 44. When the MS 2 detects the change in 
the subnet mask, it sends a UATI Update message to RAN B 
44. The UATI Update message contains the UATI assigned 
to the MS 2 by RAN A 42. RAN B 44 determines that the 
UATI was assigned by some other RAN, and queries other 
HDR RANs connected to the same network for the UATI. As 
described above, a database of UATls, PPP state informa- 
tion, IMSIs, and other information is distributed among 
HDR RANs in a wireless network. Based on the previously 
assigned UAH, RAN B 42 obtains the table information 
associated with the MS 2. Because both RAN A 42 and 
RAN B 44 are connected to PDSNj 14, RAN B 44 determines 
the temporary IMSI associated with the MS*s 2 UATI and 
notifies PDSNj 14 that the MS 2 associated with that IMSI 
has moved to RAN B 44. 

[0042] When the MS 2 leaves the coverage area 8 of 
RAN 44 and enters the coverage area 10 of RAN C 46, the 
MS J decodes the overhead messages broadcast by the base 
stations in RAN C 46. The RAN C 46 overhead messages 
contain a different subnet mask than broadcast by base 
stations in RAN B 44. When the MS 2 detects the change in 
the subnet mask, it sends a UATI Update message to RAN C 
46 containing the MS's 2 previously assigned UATI. RAN C 
46 receives the UATI Update message and queries other 
RANs connected to PDSN 2 16 to determine whether the MS 
2 received its UAH assignment from a nearby RAN. 
Because the MS 2 received its UATI assignment in RAN B 
44, which is connected to PDSN a 14, RAN C 46 will be 
unable to redirect the PPP state to itself. RAN C 46 therefore 
assigns a new UATI to the MS 2 and forces the MS 2 to 
establish a new PPP session. The MS 2 will consequently 
lose state information associated with its previous PDSNj 14 
PPP session. 

[0043] After a new PPP session is established between the 
MS 2 and PDSN 2 16, PDSN 2 16 sends an agent advertise- 
ment message to the MS 2 identifying the address of the FA 
within PDSN 2 16. Because the address of each FA is 
different, the FA address of PDSN 2 16 will be different than 
the FA address of PDSN^ 14. When the MS 2 receives an 
agent advertisement having a different address, the MS 
determines that it must re-register its IP address with the HA 
20. The MS 2 re-registers its IP address with the HA 20, for 
example according to the protocol described in association 
with FIG. 2. Using mobile IP authentication as described 
above, the HA 20 recognizes that the MS 2 has moved and 
is requesting the same IP address. If possible, the HA 20 
allocates the same IP address to the MS 2 and then redirects 
messages destined for that address to PDSN 2 16. Generally, 
the HA 20 does not send notification of the redirection to the 
original PDSN, PDSNj 14. 

[0044] FIG. 4 depicts a network configuration in a system 
using a mixture of HDR RANs 52, 56 and lx RANs 54. The 
MS 2 is initially located in the coverage area 6 of RAN A 52. 
An MS 2 designed to operate in a mixed HDR and lx system 
has attributes of both systems. For example, it has an IMSI 
stored in memory, but is also programmed to connect to an 
HDR network using a UATI. 

[0045] If HDR RANs 52, 56 are capable of performing 
authentication of IMSIs, then R-P links with PDSNs 14 and 



16 can be established using the actual IMSI of the MS 2. 
IMSI authentication may be accomplished by an HDR RAN 
using an Authentication Center on an SS7 network or using 
the AAA server 22. In an exemplary embodiment, the MS 2 
sends its IMSI to an HDR RAN at the beginning of HDR 
session negotiations. Each HDR RAN 52, 56 can then use 
the true IMSI of the MS 2 to establish its R-P links with 
PDSNs 14 and 16. Because the same IMSI is used for both 
the lx RAN 54 and the HDR RANs 52, 56, the PDSN can 
easily resolve any routing ambiguity and avoid mis-routing 
any packets addressed to the MS 2. Furthermore, if the 
previous lx RAN and the destination HDR RAN share a 
single PDSN, for example in a configuration similar to that 
of RAN A 52, RAN B 54, and PDSN, 14, the PDSN can 
re-route its R-P connection to the destination RAN and 
re-use the existing PPP state. 

[0046] However, if HDR RANs 52 and 56 are not capable 
of authenticating IMSIs, they will create temporary IMSIs 
for use in R-P links with PDSNs 14 and 16. A subsequent 
handoff from a lx RAN to an HDR RAN, for example from 
RAN B 54 to RAN A 52, can cause routing problems in a 
shared PDSN such as PDSNj 14. In an exemplary embodi- 
ment, routing problems caused by the creation of multiple 
R-P sessions having the same IP address but different IMSIs 
are addressed with minor modifications to PDSN operation. 

[0047] In an exemplary embodiment, the MS 2 connects to 
an HDR system RAN A 52, and obtains a UATI from RAN A 
52. RAN A 52 then assigns a temporary IMSI to the MS 2 in 
order to enable packet data to be routed by the FA in PDSN, 
14. The MS 2 then registers with the HA 20 as described 
above in association with FIG. 2. After mobile IP registra- 
tion is complete, the MS 2 uses the IP address assigned to it 
by the HA 20, and sends packets using a PPP state within the 
FA in PDSNj 14. Within the coverage area 6 of RAN A 52, 
the MS 2 monitors overhead messages broadcast from base 
stations in RAN A 52. 

[0048] When the MS 2 leaves the coverage area 6 of 
RAN A 52 and enters the coverage area 8 of RAN B 54, the MS 
2 decodes the overhead messages broadcast by the base 
stations in RAN B 54. As discussed above, a lx RAN like 
RAN 54 broadcasts a PZID on its overhead channels. So, 
the MS 2 receives a subnet mask from RAN A 52 and a PHD 
from RAN B 54. From the different overhead messages 
received from RAN B 54, the MS 2 determines that it has 
moved into coverage of a network having a different type of 
wireless interface. As explained below, the MS 2 and PDSNj 
14 must take special precautions to prevent packets destined 
for the MS 2 from being lost due to routing ambiguity. 

[0049] In response to the change of network, the MS 2 
sends to RAN D 54 a "fake origination" containing the actual 
IMSI of the MS 2. As a result, RAN B 54 establishes a new 
R-P connection with PDSNj 14 based on the actual IMSI of 
the MS 2. If PDSNj 14 has not previously established a PPP 
state with the MS 2 based on the actual IMSI, then PDSN r 
14 negotiates a new PPP state with the MS 2. After a new 
PPP session is established between the MS 2 and PDSN 2 14, 
PDSNj 14 sends an agent advertisement message to the MS 
2 identifying the address of the FA within PDSNj 14. 
Because the PDSN has not changed, the FA address sent in 
the agent advertisement message will be the same as that 
received from RAN A 52. As a result, the MS 2 may not 
re-register its IP address with the HA 20. Because the MS 2 
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obtained its IP address from HA 20 through RAN A 52, 
RAN a 52 assigned a temporary IMSI to the MS 2. The IP 
address being used by the MS 2 is linked to the temporary 
IMSI in the FA within PDSNj 14. All network packets 
arriving at the FA in PDSNj 14 bearing that IP address will 
be routed to RAN A 52 unless the MS 2 re-registers its IP 
address with the HA 20. 

[0050] In an exemplary embodiment, the MS 2 performs 
mobile IP re-registration whenever it moves from the cov- 
erage area of an HDR RAN 52, 56 into the coverage area of 
a lx RAN 54. For example, if the MS 2 moves from the 
coverage area 6 of RAN A 52 to the coverage area 8 of RAN B 
54, the MS 2 re-registers its address with the HA 20 even if 
the FA address received in the agent advertisement message 
is the same as the one used immediately prior. 

[0051] Unfortunately, re-registering with the HA 20 does 
not entirely solve the routing ambiguity. When the MS 2 first 
obtains its IP address from the HA 20 through RAN A 52, the 
foreign agent in PDSNj 14 associates an R-P session with 
the combination of temporary IMSI and IP address used. 
After the MS 2 moves into the coverage area of RAN B 54, 
the MS 2 re-registers with the HA 20 and is generally 
allocated the same IP address. Unfortunately, the re-regis- 
tration uses the actual IMSI of the MS 2 instead of the 
temporary IMSI initially assigned by RAN A 52. Conse- 
quently, PDSNj 14 will end up having the same IP address 
assigned to two different R-P sessions, each corresponding 
to a different IMSL When a packet arrives from the IP 
network 18 bearing that IP address, PDSN 2 14 will be unable 
to unambiguously route the packet to a RAN. 

[0052] In an exemplary embodiment, the PDSNs in a 
mixed network are modified to prevent such ambiguity. Any 
time the FA assigns an IP address to an IMSI, the FA purges 
its tables of any other entries bearing the same IP address, 
regardless of the value of the IMSI. Only one R-P session 
per IP address is allowed within an FA of a PDSN. 

[0053] In addition to the case where an MS 2 moves from 
an HDR system to a lx system, special precautions must be 
taken to avoid routing ambiguity when the MS 2 moves from 
a lx system to an HDR system. The problems may be 
particularly acute when an MS 2 establishes a connection 
through an HDR RAN, such as RAN C 56, then moves to a 
lx RAN such as RAN B 54, served by a different PDSN, 
re-registers its IP address with the HA 20 while in RAN B 54, 
and then returns to RAN C 56. In the currently proposed HDR 
standards, there is no way for an MS 2 to notify the RAN C 
56 that it has just come from a system that uses a different 
wireless interface or that it has re-registered its IP address in 
the other system. This is not a problem when moving from 
a lx RAN to a lx RAN, because the PREV_PZID in the fake 
origination allows the PDSN to determine that the MS 2 
re-registered through a different PDSN. This is also not a 
problem when moving from an HDR RAN to an HDR RAN, 
because the UATI in the UATT Request allows the destina- 
tion PDSN to determine whether the MS 2 re-registered 
through a different PDSN. 

[0054] When the MS 2 reenters the coverage area 10 of 
HDR RAN C 56 from lx RAN B 54, the MS 2 sends a UATI 
Request containing the UATI used by the MS 2 when 
previously in the coverage area 10 of HDR RAN C 56. The 
MS 2 has no way, using the currently proposed protocols, to 
notify HDR RAN C 56 of its re-registration in the intervening 



lx system. Consequently, RAN C 56 will resume network 
communications using the existing PPP state in PDSN 2 16 
associated with the UATI used previously by the MS 2. 

[0055] In an exemplary embodiment, the MS 2 always 
resets its UATI upon moving from a lx RAN to an HDR 
RAN. When the reset UATI is sent in the UAH Request, the 
HDR RAN will assign a new UATI to the MS 2 and thus 
force a mobile IP re-registration. The mobile IP re-registra- 
tion will generally result in the MS 2 being assigned the 
same IP address it was using previously. Upon completion of 
the mobile IP re-registration, the HA 20 will properly direct 
network packets to the HDR RAN, and to the MS 2. In an 
alternate embodiment, the MS 2 accomplishes substantially 
the same thing by simply forcing a PPP reset whenever the 
MS 2 moves from a lx RAN to an HDR RAN. 

[0056] In another embodiment, the HDR standard is 
altered to allow the MS 2 to initiate a LocationResponse 
message to the HDR RAN. In the existing HDR specifica- 
tion, the LocationResponse message may contain the system 
identifier (SID), network identifier (NID), and PZID of the 
previous system in which the MS 2 re-registered its IP 
address. Armed with this information, the HDR RAN could 
query its PDSN to possibly shift the R-P session to the HDR 
RAN. Or, if the PZID belongs to a lx RAN associated with 
a different PDSN, the PDSN can reset the PPP session and 
thus trigger an IP address re-registration. 

[0057] In another embodiment, the MS 2 sends a mobile 
IP AgentSolicitation message to the FA in the destination 
PDSN. Based on the address of the FA gleaned from the 
response, the MS 2 can re-register its IP address with the HA 
20 without expending the bandwidth necessary to establish 
a new PPP session. 

[0058] FIG. 5 is a flowchart showing an exemplary pro- 
cess used by the MS 2 when handing off between a lx RAN 
and an HDR RAN capable of performing IMSI authentica- 
tion. Upon detecting a change of RAN type, the MS 2 sends 
its IMSI to the destination RAN at step 502. If the destina- 
tion RAN is a lx RAN, the IMSI may be sent in the 
origination message for a "fake origination." If the destina- 
tion RAN is an HDR RAN, the IMSI may be sent in a 
configuration message while the new HDR session is being 
negotiated. 

[0059] If the PDSN connected to the destination RAN 
does not have an R-P session associated with the IMSI of the 
MS 2, the PDSN will establish a new PPP session with the 
MS 2. At step 504, the MS 2 determines whether a new PPP 
session has been established with the PDSN. The establish- 
ment of a new PPP session by the PDSN could mean that the 
PDSN has no existing PPP state associated with the IMSI of 
the MS 2. Alternatively, the establishment of a new PPP 
session by the PDSN could mean that the PDSN cannot 
transfer an existing PPP state from an R-P session of a 
previous RAN to the destination RAN. In either case, the 
PDSN will generally send an agent advertisement message 
to the MS 2 indicating the address of the FA within the 
PDSN. If the previous RAN providing service to the MS 2 
was connected to the same PDSN, then it might not be 
necessary to re-register mobile IP with the HA 20. The HA 
20 would forward packets to the correct PDSN. However, if 
the previous RAN providing service to the MS 2 was 
connected to a different PDSN, then the MS 2 should 
re-register mobile IP in order to notify the HA 20 of the new 
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PDSN address. Because the MS 2 cannot determine whether 
the new PPP state was necessitated by a change of PDSN, 
the MS re-registers its mobile IP address with the HA 20 at 
step 506. 

[0060] If, at step 504, the MS 2 determines that no new 
PPP session has been established with the PDSN, then the 
MS 2 determines, at step 508, whether a mobile IP re- 
registration occurred in the previous RAN type. As dis- 
cussed above, protocols used with the different wireless 
interfaces are designed to manage movement of the MS 2 
among different RANs of the same type. Thus, when the MS 
2 moves among RANs of the same type, no routing ambi- 
guity results. When moving among lx RANs, the MS 2 
sends information about the previous RAN such as the PZID 
to allow the destination RAN to determine whether a new 
PPP session should be established. When the MS 2 is 
moving among HDR RANs, the destination RAN deter- 
mines whether a new PPP session is needed by comparing 
the UATI received from the MS 2 in a UATI update message. 

[0061] However, when the MS 2 returns to a RAN having 
a different type of wireless interface, the messages it sends 
to the destination RAN do not identify a previous RAN of 
a different type. If the destination RAN is an HDR RAN, the 
MS 2 cannot send a previous PZID value in a UAH update 
message. Likewise, the MS 2 cannot send a UATI in a lx 
origination. If the previous RAN and the destination RAN 
are connected to different PDSNs, and the MS 2 re-regis- 
tered its mobile IP address with the HA 20 in the previous 
system, the HA 20 will still send subsequent packets 
addressed to the MS 2 to the previous RAN's PDSN. In 
order to prevent such routing ambiguity, if the MS 2 
performed a mobile IP re-registration in the previous RAN 
type, it re-registers its mobile IP address at step 506. 

[0062] FIG. 6 is a flowchart showing an exemplary pro- 
cess used by the MS 2 when handing off between different 
RANs, when it is not known whether the HDR RANs are 
capable of performing IMSI authentication. Upon detecting 
a change of RAN, the MS 2 sends its IMSI to the destination 
RAN at step 602. The MS 2 then determines, in steps 604, 
606, 608 which of four possible handoff types is required: 
(1) HDR-to-HDR; (2) lx-to-lx; (3) HDR-to-lx; or (4) 
lx-to-HDR. The MS 2 processes each different handoff type 
differently. 

[0063] At step 604, the MS 2 determines the type of the 
previous RAN. If the previous RAN was an HDR RAN, the 
MS 2 then determines, at step 606, the type of the destination 
RAN. If the destination RAN is also HDR, then the MS 2 
sends a UATI Request to the destination RAN at step 608. 
Then, the MS 2 determines, at step 618, whether the 
destination PDSN established a new PPP session. If the 
destination PDSN did not establish a new PPP session, the 
MS 2 continues normal operation and can send and receive 
packet data through the destination RAN. Otherwise, the MS 
2 re-registers its mobile IP address with the HA 20 at step 
624. 

[0064] If, at step 604, the MS 2 determines that the 
previous RAN was a lx RAN, the MS 2 then determines, at 
step 614, the type of the destination RAN. If the destination 
RAN is also lx, then the MS 2 sends an origination message 
to the destination RAN at step 616. As discussed above, this 
origination message can be a "fake origination" containing 
a DRS field value of 0. The origination message contains the 



MS*s 2 IMSI and any system identification values associated 
with the destination RAN that are different from those for 
the previous RAN, such as the PZID. Based on the infor- 
mation in the origination message, the PDSN connected to 
the destination RAN may establish a new PPP session. At 
step 620, the MS 2 determines whether the destination 
PDSN established a new PPP session. If the destination 
PDSN did not establish a new PPP session, the MS 2 
continues normal operation and can send and receive packet 
data through the destination RAN. Otherwise, the MS 2 
receives an agent advertisement at step 622 and compares 
the FA address to the FA address previously used to register 
a mobile IP address with the HA 20. If the previous FA 
address is different from the address of the destination FA, 
the MS 2 re-registers its mobile IP address at step 624. 
Otherwise, the MS 2 continues normal operation and can 
send and receive packet data through the destination RAN. 

[0065] If, at step 606, the MS 2 determines that the 
destination RAN is a lx RAN, then the MS 2 sends an 
origination message at step 610. This origination message 
can be a "fake origination" containing a DRS field value of 
0. In an exemplary embodiment, when handing off to an 
HDR RAN, the MS 2 saves the system identification values 
of the previous lx RAN. The origination message contains 
the MS's 2 IMSI and may contain previous system identi- 
fication values such as PZID, SID, or NID. After sending the 
origination at step 610, the MS 2 continues to step 618 
described above. 

[0066] If, at step 614, the MS 2 determines that the 
destination RAN is an HDR RAN, then the MS 2 sends a 
Location Update message at step 612. In an exemplary 
embodiment, the Location Update message contains the 
PZID, SID, and NID of the previous lx RAN. In an 
exemplary embodiment, the Location Update message con- 
tains a Location Value field as defined in the HDR specifi- 
cation. The destination HDR RAN may use the information 
in the Location Update message to determine whether the 
MS 2 is handing off from a previous RAN connected to a 
different PDSN. If the previous RAN and the destination 
RAN share a PDSN, then the PDSN may be able to move the 
R-P state associated with the MS 2 to the destination RAN 
without requiring a mobile IP re-registration or establish- 
ment of a new PPP session. After sending the Location 
Update message, the MS 2 continues to step 618 described 
above. 

[0067] FIG. 7 (FIGS, la and lb) is a flowchart of a 
handoff process for a destination network including the 
destination PDSN and the destination RAN. At step 704, the 
destination RAN receives identification information from 
the incoming MS 2. The identification information may 
include an IMSI, a UATI, or system identification informa- 
tion associated with the previous RAN such as PZID, SID, 
or NID. As discussed above, the types of identification 
information received from an incoming MS 2 may vary 
based on the wireless interfaces used by the previous and 
destination RANs. 

[0068] At step 706, the destination network searches for 
an existing PPP session associated with the incoming MS 2. 
In an HDR network, this can include searching for IMSIs, 
UATls, or other information distributed among multiple 
HDR RANs. In a lx network, this can include searching for 
the IMSI of the MS 2 in a database within the destination 
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PDSN. In either type of network, the search may include 
authenticating the IMSI received from the MS 2. If the 
destination network supports IMSI authentication, and the 
MS 2 cannot be successfully authenticated, the network will 
either deny packet services to the MS or, in the case of an 
HDR RAN, will assign a temporary IMSI to identify the R-P 
session in the DESTINATION PDSN. Ultimately, at step 
708, the DESTINATION PDSN determines whether or not 
it has an existing R-P session associated with the incoming 
MS 2. 

[0069] If a session can be found, then at step 710 the 
destination network determines whether an identified pre- 
vious RAN is connected to the destination PDSN. If so, then 
the destination PDSN redirects its R-P session to the desti- 
nation RAN at step 712, and packet data service to tbe MS 
2 can continue without mobile IP re-registration or estab- 
lishment of a new PPP session. If a session cannot be found, 
then at step 714 the destination PDSN establishes a new PPP 
session with the incoming MS 2. After the new PPP session 
is established, the destination PDSN sends, at step 716, an 
agent advertisement containing the address of the FA within 
the destination PDSN to the incoming MS 2. At step 718, if 
the agent advertisement does not cause the incoming MS 2 
to re-register its IP address with the HA 20, then packet data 
service to the MS 2 can continue. 

[0070] If, at step 718, the incoming MS 2 re-registers its 
IP address, then at step 720, the destination PDSN monitors 
the IP address assigned to the incoming MS 2 through its FA. 
If the assigned IP address matches tbe IP address associated 
with any other R-P sessions in the PDSN, then at step 722 
the PDSN terminates the other R-P sessions. The PDSN 
terminates such other R-P sessions even if they have differ- 
ent IMSIs to prevent any routing ambiguity. After step 722, 
or if, at step 718, the incoming MS 2 does not re-register its 
IP address, then packet data service to the MS 2 can 
continue. 

[0071] FIG. 8 shows an exemplary MS 2 apparatus. As 
discussed above, the MS 2 may have a data connection 12 
to an external terminal or device such as a personal or laptop 
computer (PC) 4. In such a configuration, the MS 2 includes 
a local interface 812 to provide necessary conversions of 
data connection signals and digital data. The local interface 
812 can be any of a variety of cabled interface types such an 
ethernet, serial, or universal serial bus (USB). Alternatively, 
the Local interface 812 may provide a wireless connection 
such as an infrared or other optical connection or a radio 
connection such as Bluetooth or IEEE 802.11. 

[0072] Instead of providing a connection to an external PC 
4, the MS 2 may provide direct access to the IP network 18. 
For example, the MS 2 may include a web browser appli- 
cation using such protocols as the Wireless Application 
Protocol (WAP). In such an incorporated application, the 
local interface 812 may take the form of a user interface 
including keypads, LCD displays, or touch-sensitive dis- 
plays such as pen input interfaces like those commonly used 
on handheld personal digital assistant devices (PDAs), or 
any other input interface appropriate for wireless packet data 
user applications. 

[0073] In an exemplary embodiment, the local interface 
812 provides application data to a control processor 804. 
The control processor 804 may be a general-purpose micro- 
processor, digital signal processor (DSP), programmable 



logic device, application specific integrated circuit (ASIC), 
or any other device capable of performing the functions 
described herein. The handset user input interface and 
handset display may include a keypad, a liquid crystal 
display (LCD) pen input interface such as those commonly 
used on handheld personal digital assistant devices (PDAs), 
or any other input interface appropriate for wireless packet 
data user applications. 

[0074] In addition, the control processor 804 is configured 
to perform the MS 2 processing described in conjunction 
with FIGS. 1-7, such as requesting IP resources, managing 
PPP sessions, and other network protocol processes associ- 
ated with the various wireless interfaces. The control pro- 
cessor 804 may be a single processor, or may include 
multiple separate processors such as a microcontroller for 
managing user interface functions through the local interface 
812 and a DSP for managing wireless interface protocols. 

[0075] The MS 2 includes a memory 802 for storing the 
various types of data and information needed during opera- 
tion of the control processor 804. The memory 802 may be 
a single device or may include multiple devices such as 
non-volatile memory including flash memory, static or 
dynamic random access memory (RAM), or erasable or 
non-erasable read-only memory (ROM). The entire memory 
802 or portions thereof may be incorporated into a single 
device with the entire control processor 804 or portions 
thereof. The memory 802 may contain such information as 
the executable code for the control processor 804, the IMSI, 
the shared secret information used to register a mobile IP 
address, the address of the HA 20, and the mobile IP address. 
Additionally, the memory 802 is configured to store tempo- 
rary copies of packet data transmitted to and received from 
the wireless network, and all the state variables necessary for 
providing packet data services. 

[0076] In an exemplary embodiment, data to be sent to the 
wireless network is encoded, modulated, and interleaved in 
a modulator (MOD) 806, and amplified and upconverted in 
a transmitter fTMTR) 808 before being transmitted through 
a diplexer (DIP) 810 and an antenna 814. Data received from 
the wireless network through the antenna 814 is gain- 
controlled and downconverted in a receiver (RCVR) 816, 
deinterleaved, demodulated, and decoded in a demodulator 
(DEMOD) 818 before being processed by the control pro- 
cessor 804. The modulator (MOD) 806, transmitter (TMTR) 
808, receiver (RCVR) 816, and demodulator (DEMOD) 818 
are capable of operating using multiple types of wireless 
interfaces, for example lx and HDR. If necessary, the MS 2 
includes multiple modulators, transmitters, receivers, or 
demodulators as necessary for compatibility with the mul- 
tiple types of wireless interfaces, including lx, HDR, 
W-CDMA, and EDGE. 

[0077] The previous description of the preferred embodi- 
ments is provided to enable any person skilled in the art to 
make or use the present invention. The various modifications 
to these embodiments will be readily apparent to those 
skilled in the art, and the generic principles defined herein 
may be applied to other embodiments without the use of the 
inventive faculty. Thus, the present invention is not intended 
to be limited to the embodiments shown herein but is to be 
accorded the widest scope consistent with the principles and 
novel features disclosed herein. 
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What is claimed is: 

1. A method of performing a handoff of a mobile station 
between a first radio access network of a first type and a 
second radio access network of a second type, comprising: 

determining, at the mobile station, whether changing from 
communicating over the first radio access network to 
communicating over the second radio access network 
will cause routing ambiguity for data sent to and from 
the mobile station; and 

triggering, at the mobile station, a re-registration of a 
network address of the mobile station if changing from 
communicating over the first radio access network to 
communicating over the second radio access network 
will cause routing ambiguity for data sent to and from 
the mobile station. 

2. In a packet data serving node of a communications 
network, a method of compensating for a handoff of a 
mobile station between a radio access network of a first type 
and a radio access network of a second type, comprising: 

determining, at the packet data serving node, whether 
multiple radioaccess-network-to-packet-data-serving- 
node (R-P) connections are being created for the same 
mobile station; and 

terminating, at the packet data serving node, redundant 
R-P connections resulting from movement of the 



Jun. 6, 2002 



mobile station between a radio access network of a first 
type and a radio access network of a second type. 

3. The method of claim 2, further comprising monitoring, 
at the packet data serving node, network address re-regis- 
trations of mobile stations. 

4. A mobile station, comprising: 

a control processor; and 

a memory coupled to the control processor and containing 
instructions executable by the processor to determine 
whether handing off from a radio access network of a 
first type to a radio access network of a second type will 
cause routing ambiguity for data sent to and from the 
mobile station, and triggering a re-registration of a 
network address of the mobile station based on the 
determination. 

5. A mobile station, comprising: 

means for determining whether handing off communica- 
tions from a radio access network of a first type to a 
radio access network of a second type will cause 
routing ambiguity for data sent to and from the mobile 
station; and 2means for triggering a re-registration of a 
network address of the mobile station based on the 
determination. 

***** 
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